Games of Daze/Infomagic - Games of Daze (Summer 1995) (Disc 1 of 2).iso/x2ftp/msdos/docs/hdtech01.txt

Internet Message Format | 1995-03-26 | 14KB

From: [e-mail] (Nicholas Majors)
Subject: Chapter 1 - Technicians' Guide to Hard Disks (REPOST)
Date: 25 Mar 1995 18:45:09 GMT


========================================================================
     Chapter 1 - TECHNICIANS' GUIDE TO PC HARD DISK SUBSYSTEMS
========================================================================
copyright (c) 1992, 1995

Nicholas Majors,

DATA RECOVERY LABS
(division of Data Recovery Services Inc)    Voice : 1-416-510-6990
1315 Lawrence Avenue East - Unit 502        FAX   : [phone]
Don Mills, Ontario, Canada M3A 3R3          Email : [e-mail]
========================================================================

INTRODUCTION :

This booklet (now electronic) is published as a service of Data
Recovery Labs.  Its purpose is to provide the fundamental knowledge of
concepts and terminology that is necessary to deal with the
complexities of hard disk subsystems.  It is not a technical reference
guide and should not replace original documentation made available by
manufacturers.

Every day we meet and deal with technicians and support personnel who
install, upgrade and maintain hard drives, without knowing exactly
what they are and how they work.  Gaining a working knowledge of disk
subsystems is not a simple task and requires much study - and -
experience.  Don't expect any book, training course, or manual to make
you into an expert. However, if you read and understand most of this
material, you will be off to a fine start.

The principal author is Nick Majors.  He has been in the industry
since 1979, designing and developing hardware and operating system
enhancements and performance tools.  He is an experienced machine
language programmer and has provided technical training to support
personnel for some of Canada's leading banks, corporations, government
departments and PC service organizations.  He is Manager of Technical
Services for Data Recovery Labs which he founded in 1989.

While this booklet deals primarily with PC and PC compatible
platforms, there is much information to benefit support personnel with
other hardware platforms.

Every effort has been made to ensure accuracy, but misprints and
ambiguities may still remain, so please use caution.

========================================================================
HISTORY AND OVERVIEW :

The original IBM PC, introduced in 1981, did not support any type of
hard drive.  Program code in the BIOS did not recognize any such
device and early versions of DOS precluded mass storage by limiting
the maximum number of directory entries.  This is not surprising when
you consider that the original 4.77 MHz PC came with 16 K of RAM,
expandable to 64 K on the motherboard.  Even floppy drives and a disk
operating system were options to upgrade the built in cassette
recorder port and ROM basic.

To utilize a hard drive in a PC requires:

   - a Hardware IRQ (interrupt request)
   - I/O port addresses for the controller
   - a DMA channel (now optional)
   - low level program code
   - a physical interface to the bus (expansion slot or built-in)
   - operating system support
   - sufficient power and cooling

After DOS 2 introduced the sub-directory system and support for mass
storage devices, companies started selling hard drives for the PC.
These were external cabinets that contained the disk itself, a
controller card, and a dedicated power supply (since the PC's 63.5 watts
were insufficient).  Migrating from other architectures, these units
connected to the PC through cabling to an 8 bit adapter card that
plugged into an available expansion slot. These subsystems were
configured to use one of the available IRQ's, DMA channels, a range of
I/O ports, and program code that was made available through a device
driver loaded into memory after startup (booting from a floppy).

In 1983, the IBM XT (eXTended) was unveiled with its built-in 10 MB
fixed disk. IBM worked with a company (Xebec, I think) to take the
controller components normally located in the external cabinet and
build them right onto a bus interface card, creating what we commonly
call the "hard disk controller".

Program code was provided by a ROM chip on the controller card which
supplemented subroutines in the BIOS, and the internal power supply
was upgraded to 135 watts to provide power for the internally mounted
drive.

The XT design utilized :

   - IRQ 5
   - I/O port addresses 320-32f
   - DMA channel 3
   - Program Code from adapter ROM at c8000
   - DOS 2.0 or higher

Several companies started manufacturing and selling similar
drive/controller packages with various improvements including higher
capacities, superior performance and built-in floppy controller
components on the same card (to save an expansion slot). These third
party subsystems could even be added to an original PC, so long as the
internal power supply was also upgraded.

In 1984, the IBM AT (Advanced Technology) brought a complete overhaul
to hard disk systems. Program code was included in the motherboard ROM
BIOS, eliminating the need for a ROM chip on the new 16 bit controller
card, and a higher quality drive improved access times. The system
included use of newly added higher IRQ's, eliminated the use of DMA
for hard drives, and changed the range of I/O addresses.

The AT design utilized :

   - IRQ 14
   - I/O port addresses 1f0-1f8
   - DMA channel - none
   - Program Code from motherboard ROM BIOS
   - DOS 2.0 or higher

Hardware configuration details for the AT, including hard disk
parameters, were stored in a low power CMOS chip connected to a small
battery, eliminating many of the motherboard configuration dip
switches and jumpers.  The battery allowed information to be
maintained while the computer was turned off and information could be
changed by running a setup program from disk.

The original AT supported 14 different drive types, recognizing
specific hard disks ranging from 10 to 112 MB.  Any drive with
physical parameters that did not match one of these types needed a ROM
extension on the controller card or a device driver loaded during
boot-up.

DOS versions prior to 4.0 (or 3.31) did not support partitions larger
than 32 MB no matter how big a drive was.  This was because of sector
numbering that could not exceed 16 bit values (up to 65,536 sectors).
To make a larger partition required the use of special software like
Ontrack's Disk Manager.  This software was so popular that many drive
manufacturers shipped it with their product.  Unfortunately, while
this offered one of the better solutions, it did pose compatibility
problems for many disk utilities because, in effect, you had a non-DOS
partition.

Many people opted instead to divide their drives into 32 MB partitions
creating a C: D: E: etc. up to the physical capacity.  Prior to DOS
3.3, even this was not possible, because DOS did not recognize
extended partitions!

The number of drive types supported by CMOS has expanded to over 40
and most current BIOS's provide a user definable type to allow
parameters to match any drive. Most PC's today still rely on this
original CMOS drive type scheme to configure and control hard disks,
though many architectures and BIOS's have changed how the information
is stored and updated.

This inherently creates certain limiting factors, including a problem
with more than two hard drives and BIOS/OS limits to recognizing more
than 1024 cylinders, 16 heads and 63 sectors per track.   Various
technologies must be used to translate non-compliant physical
geometries into logical parameters recognized by the system to
maintain compatibility with operating system and utility programs that
are tied to these limits.

With each sector holding 512 bytes of data this allows for drives no
larger than 504 MB.
(1024 X 16 X 63 = 1,032,192 sectors X 512 = 528,482,304 bytes)

To understand this limit, we have to examine how hard drives are
accessed by a PC.

Primarily, I/O commands are sent to the controller via a range of
reserved port addresses.  This is a very complicated and tedious
process and the ROM BIOS includes a subroutine (INT 13) to perform
these tasks for you. The DOS operating system then has certain
functions that further simplify the process.   They include INT 25/26
functions to read and write absolute sectors to the drive as well as
higher level functions (INT 21) to Open files, Close files, Write data
to files, etc. Most programs rely on these DOS functions to control
access to hard drives and DOS in turn calls the INT 13 BIOS
subroutines which do the actual I/O commands.

All of these subroutines are assembly language code that are  loaded
into memory from either your BIOS chip(s) or Operating System files at
startup.

Assembly language routines store and manipulate values in registers
within the CPU.  The lowest common denominator for INTEL based PC's is
16 bit registers.  Any program or routine that wants to be backward
compatible, must use these base registers whether run on an 8088 or a
Pentium.  This basic INT 13 is the backbone of PC compatibility and
uses 16 bit registers in the following way:

   DX - 8 bits for head number - 8 bits for drive number
   CX - 10 bits for cylinder number and 6 bits for sector number

The largest 10 bit number possible is 1023 hence the limit on cylinder
numbers (from 0-1023) and the largest 6 bit number is 63 (from 1-63)
allowing 63 sectors per track.

But note - the DX register allows a maximum of 255 heads, not the 16
that original specifications called for.  This is what allows various
translation schemes to deal with drives up to 8 GB while remaining INT
13 compatible.

If the DX register allows 8 bits for drive number, shouldn't it be
able to control 255 drives instead of only two?

When the INT 13 sends commands to your controller, it must know the
physical geometry of the drive in question.  During initialization of
the PC, values for disk types are read from CMOS and stored into an
area of RAM called the BIOS DATA AREA.  Pointers to those entries are
stored in the Interrupt Vector Table (at addresses 0:104h and 0:118h).
The table only reserved pointers for two drives, so even if your CMOS
held more values, the standard routines wouldn't know how to deal with
them.

Why were the INT 13 routines so limited?  They were written at a time
when 10 and 20 MB drives were the norm, and 120 MB was unbelievable.
They were designed to communicate with a specific controller
interface, the ST412/506 standard (WD1003 controller), and the specs
for passing parameters included only 10 bits for cylinders number, 4
bits for head number and a single bit for drive number.

Some of these limitations have been overcome in the past by replacing
the PC's INT 13 sub- routines with code that could recognize and deal
with different devices. That's why virtually all SCSI adapter cards
include a ROM chip and you must set the drive type to ZERO.  In
effect, no standard drives installed for the motherboard BIOS to
control.

NetWare and other advanced Operating Systems use the drive type only
long enough to boot- up and then replace the INT 13 code with their
own device drivers.  You then need to load a different .DSK file
written specifically for each type of controller.

In the past couple of years, many motherboard and controller BIOS's
have been enhanced to deal with ever increasing demands, but the
process of establishing new standards has led to continuing confusion
and compatibility problems.

========================================================================
                          END OF CHAPTER 1
========================================================================

COMING SOON - CHAPTER 2 - Inside Hard Drives and Controllers :
                        - Parts and Components
                        - also suggestions for must reading material

========================================================================
NOTICES & PERSONAL RANTS :
========================================================================

INTERNET APOLOGIES : The original artiticle, offering this booklet, was
posted Jan. 29, 1995.  I have had lots of replies, BUT - all kinds of
people insist on replying by follow-up articles instead of private
Mail.  This proved downright embarrassing! I only wanted E-MAIL
responses.  Sorry for the clutter!

DISTRIBUTION : Chapters 1-2 will be sent by E-Mail to some 2,700
people who requested it and is being posted to various News groups.
The work to maintain a mailing list is much more trouble than it's
worth, therefore - future chapters will be posted to a select number of
New Groups and Bulletin Boards.

Files can be obtained by ftp.  Look for "hdtech??.txt"

ftp site: archive.umich.edu in /msdos/info/disk

mirror  : wuarchive.wustl.edu in /systems/ibmpc/umich.edu/info/disk
          (Note - This mirror is not always up to date)

ftp site: ftp.wi.leidenuniv.nl in /pub/faqs

Also Daniel Tauritz has a home page with links to this document plus a
number of hard drive FAQs:

          http://www.wi.leidenuniv.nl/~dtauritz/ata.html

If anyone specifically requires E-mail, send me a note with "e-mail
please" as the subject. I will be glad to accommodate them, assuming
it's a manageable number.  I cannot provide hard copy or S-Mail.

RIGHTS : This material is copyright (C) 1992,1995 by Nicholas Majors
and Data Recovery Labs.  Feel free to distribute it as either hard
copy, electronically, or by BBS - with full copyright credit to both.

COMMENTS & CRITICISM : I look forward to receiving suggestions,
improvements, additions, (and yes even compliments) to this material.
Please bear in mind who this has been written for - tech support
personnel, not end-users and not engineers or hardware designers.

========================================================================